Node / public / precursor-lxmfchat.git / files / xous-core / docs / flash.md

Displaying Rendered • View raw • Download

Xous is designed to operate from a SPI FLASH filesystem. The key properties assumed of the

underlying implementation are as follows:

• XIP-capable

• Memory-mapped

• 4kiB erase sectors (same as page size)

• Transparent bad block mechanism

• ~100k erase/program cycles per sector

The FLASH memory used in the Precursor implementation is a Macronix MX66UM1G45G, which

is a 128MiB part, upgradable to higher capacities.

In Precursor, FLASH memory is located at a base of 0x2000_0000, which is the constant

T383838HW_SPIFLASH_MEM in the T383838utra, and the length is coded as T383838HW_SPIFLASH_MEM_LEN.

Below is a map of the FLASH memory. For completeness, note that the hardware

boots from location 0x0000_0000, from 32kiB a non-Xous boot ROM that is compiled into

the FPGA binary image itself. This ROM currently consists of just a few instructions

to jump to the Xous loader, but eventually this will need to house the code that does

public key signature verification of the Xous kernel itself before jumping to it.

Also note that main SRAM is, by default, battery-backed, so during shutdown, the RAM

image stays resident. This means no space is allocated in FLASH for hibernation or standby.

Finally, everything in the memory layout up until the PDDB is considered to be largely

static data, only written during firmware and software updates. Therefore, no provision

exists for sector-sparing or wear levelling; we instead rely on the 100k-cycle write

endurance of the underlying hardware. The PDDB itself will have to implement some form

of wear leveling, however.

The table below is transcribed into Xous here.

There is one wart, where the font maps are defined in another file, as they are generated by a script in the loader when the font maps are automatically packed into memory, and targeted for the graphics server.

T282828

The EC update block is further structured as follows:

T282828

The firmware control pages have the following structure:

T282828

The EC FW has a versioning block, appended to the end of the firmware. This block is included in the "actual firmware length" for the purposes of hashing and signature checks. The block contains the following data, aligned to the very end of firmware:

T282828

The WF200 firmware also has a hash embedded at the start. It has the following structure:

T282828

The csr.csv block is further structured as follows:

T282828

Prior to the creation of the PDDB, some hard-coded audio data is loaded for development purposes.

This documents their location in FLASH. The samples are shorter than the allocated regions, but the WAV headers encode their actual length.

T282828